home *** CD-ROM | disk | FTP | other *** search
-
- CURRENT_MEETING_REPORT_
-
-
- Reported by Fred Baker/ACC
-
- Minutes of the joint sessions of IPLPDN and PPPEXT Working Groups
-
- The two Working Groups met in joint session to discuss protocol
- specifications common to both. Since the objectives and requirements of
- the two Working Groups differ in some key respects, there was
- considerable difference of opinion at the outset. The Chairs wish to
- congratulate the various parties in the discussions on the level of
- personal restraint and professionalism displayed during the discussions.
- Would that there were even more of both.
-
- Two subjects were discussed: how to share load among a set of parallel
- links to increase apparent bandwidth and potentially reduce latency
- between two sites, and how the IPLPDN Group might best avail itself of
- the facilities found in PPP negotiation.
-
- Load Sharing
-
- Two proposals for load sharing were outlined. Fred Baker briefly
- reminded the Group of his previous proposal to use ISO Multilink
- Procedures as described in ISO 7776 and ISO 7428. Keith Sklower
- discussed his proposal to use the existing RFC1294 segmentation
- encapsulation to achieve traffic ordering in much the same way that
- multilink does, and provide the option of data fragmentation and
- reassembly.
-
- The consensus of the Group preferred Keith's approach, but recommended
- that two currently unused bits be assigned the purposes of the ISO
- Multilink Protocol's RESET and RESET ACKNOWLEDGE flags to facilitate
- synchronization of links when bringing them into and out of service.
- Concerns were raised about the size of the resequencing buffer, most
- especially when the link speeds are mismatched. Joel Halpern and Craig
- Fox will provide input to Keith concerning a solution to this that they
- worked out; Keith will appropriately edit his proposal for further
- discussion on the IPLPDN mailing list.
-
- PPP Parameter Negotiation for Frame Relay
-
- The consensus we reached is encapsulated in the following points.
-
-
- o By default, Frame Relay services will conform to RFC1294. This
- implies that if two systems attempt to communicate, one using
- RFC1294 and the other using PPP services, the system desiring PPP
- services will use RFC1294 instead.
-
- o There may be a requirement to negotiate services in both PVC and
- SVC environments.
-
- 1
-
-
-
-
-
- o Negotiation uses PPP negotiation frames encapsulated in a manner
- conforming to RFC1294.
-
- o The system receiving a PPP negotiation frame may choose to ignore
- and discard it, either because the system is old or because it is
- configured to do so. Once both systems have decided to negotiate,
- the full PPP negotiation FSM takes effect.
-
- o There may be LCP Configuration Options to modify the encapsulation
- on a virtual circuit.
-
- o We jointly agree to specify this.
-
- o The PPP encapsulations of choice are:
- First choice:
-
- 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Q.922 Address Field |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Control Field | NLPID (TBD) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | PPP PID |
-
-
- Second choice:
-
- 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Q.922 Address Field |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Control Field | PAD (00) |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | NLPID=80 | OUI = 00 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | OUI = 00-00 |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | Ethernet Packet Type TBD |
- +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
- | PPP PID |
-
-
- Use of the first encapsulation is subject to assignment of an NLPID
- value by X3S3. Bill Simpson reports that Lyman Chapin feels has
- assigned a block of NLPID values to the IAB for IETF purposes.
-
- o By default, data which has an existing RFC1294 encapsulation should
- be encapsulated as in RFC1294, unless the two systems agree, using
- LCP negotiation, to use the above encapsulation for data. Data
- which has no defined RFC1294 encapsulation but has a PPP
- encapsulation must use the above for data regardless of the outcome
- of that negotiation. Data which has no defined PPP encapsulation
-
- 2
-
-
-
-
-
- but has an RFC1294 encapsulation must use the latter regardless of
- the outcome of the negotiation.
-
- o Because it is specified in the PPP FSM, all data flow stops during
- LCP negotiation. Data streams having PPP NCPs do not restart until
- their PPP NCP has reached the OPEN state. Data Streams not having
- PPP NCPs may restart upon the LCP reaching the open state. As in
- PPP, subsequent renegotiation of an NCP affects only its data.
-
-
- Keith Sklower and Bill Simpson have agreed to merge their efforts and
- their current proposals to implement this consensus. The output will be
- discussed on the IPLPDN list.
-
- IPLPDN and PPPEXT expect to have two joint meetings at the Amsterdam
- IETF.
-
-
-
- 3
-